In diesem Interview spricht Eberhard Wolff über die Entstehung von isolierten Modulen. Der Zusammenhalt der Architektur ist besonders bei Projekten über Firmengrenzen hinweg sehr herrausfordernd und kann nur mit der richtigen Kommunikationsstrategie gewahrt werden.

Erörterung zu Conway’s Law

Melvin E. Conway hat 1968 die Beobachtung angestellt, dass das Design von Systemen Kopien der Kommunikationsstrukturen der Unternehmen darstellen, die diese Systeme entwickeln. Was bedeutet das konkret für Software-Architekten?
Hängen Software-Architekten in ihrer Arbeit davon ab, wie ein Unternehmen mit den Kunden kommuniziert, wie sich die Abteilungen des Unternehmens untereinander austauschen, wie die IT intern aufgebaut ist, wie die Mitglieder der einzelnen Team miteinander reden und zusammenarbeiten?

W-JAX: Ein Beispiel aus deiner Praxis: Wo wurde dir Conway’s Law ganz deutlich vor Augen geführt?

Eberhard Wolff: Für mich ist das Gesetz von Conway ein wichtiges Werkzeug, um zu verstehen, was in Projekten vor sich geht. Wenn unterschiedliche Dienstleister für die verschiedenen Teile des Projekts verantwortlich sind, dann beeinflusst das die Kommunikation und die Architektur.

Kommunikation über Firmengrenzen hinweg ist aufwändig, insbesondere wenn die Teams am jeweiligen Firmenstandort des Dienstleisters arbeiten. So entstehen sehr isolierte Module. Ein Zusammenhalt der Architektur ist schwierig.

Dass Teams, die nach Fachlichkeiten aufgestellt sind, die Architektur beeinflussen, haben wir schon vor 15 Jahren in einem Projekt festgestellt. Allerdings haben wir es damals noch nicht zur Steuerung der Architektur genutzt.

Software-Architektur ist nur scheinbar ein technisches Thema.

W-JAX: Welches Mittel hat sich in deiner Praxis bewährt, um den Effekten von Conway’s Law zu begegnen?

Eberhard Wolff: Bei der Einstellung von Mitarbeiten oder bei Umorganisationen werden Architekten oft mit einbezogen, da sie die technische Expertise der Personen am besten abschätzen können. Dann können sie auch andere organisatorische Maßnahmen vorschlagen, um die Architektur zu beeinflussen.

Generell ist Software-Architektur nur scheinbar ein technisches Thema. Ein Architekt muss Ideen und Kritik aus den Teams aufnehmen und die Architektur kommunizieren. Diese Maßnahmen beeinflussen die Kommunikationsstrukturen und damit die Architektur.

W-JAX: Ist Conway’s Law umkehrbar? Hängt gute Architektur also von den Organisationsstrukturen eines Unternehmens ab?

Eberhard Wolff: Conway’s Paper diskutiert, dass Projekte zu großen Teams neigen. Das ist gut für das Prestige, und bei einem Fehlschlag kann man argumentieren, dass selbst ein sehr großes Team die Aufgabe nicht lösen konnte. Dann kommt das Gesetz von Parkinson: Eine Aufgabe hält alle verfügbaren Mitarbeiter beschäftigt. Das Gesetz erklärt die Beobachtung, dass eine Verwaltung beliebig mehr Mitarbeiter einstellen kann – die Aufgaben dauern gleich lange.

Ein großes Projekt hat aber entsprechende Kommunikationsschwierigkeit und dann auch Herausforderungen in der Architektur. Also hat Conway schon in seinem Paper erläutert, dass gute Architektur nur mit guter Kommunikation möglich ist.

Architekten müssen die Architektur ständig kritisch hinterfragen und weiterentwickeln.

Der Software Architecture Track auf der JAX 2018

W-JAX: Jeff Sussna hat einmal in einer Keynote darauf hingewiesen, dass Conway aus seiner Ursprungsthese etwas seiner Meinung nach viel Wichtigeres folgert . Dass es für jedes gegebene Design nämlich immer ein noch besseres geben könnte. Wichtiger als gutes System-Design wird damit die Fähigkeit zum Redesign. Würdest du dem zustimmen? Und wenn ja, wie kann man dem in der Software-Architektur Rechnung tragen?

Eberhard Wolff: Problematische Architekturen entstehen, weil der richtige Zeitpunkt zur Änderung verpasst worden ist. Nicht nur die Anforderungen ändern sich. Es gibt auch neue Technologien und Techniken, die neue Verbesserungen ermöglichen. So ist es unausweichlich, dass eine Architektur sich immer weiter vom Optimum entfernt.

Also müssen Architekten die Architektur ständig kritisch hinterfragen und weiterentwickeln. Vorsorglich Flexibilität in Architekturen einzubauen führt hingegen zu erhöhten Aufwänden, und am Ende ist die Flexibilität leider meistens an den falschen Stellen.

W-JAX: Welcher Aspekt in der aktuellen Diskussion um Softwarearchitektur ist für dich besonders anregend für deine Arbeit?

Eberhard Wolff: Continuous Delivery (CD) ist für mich ein wichtiger Fortschritt für die Produktivität. Microservices unterstützt CD in der Architektur. Die beiden Themen finde ich so wichtig, dass ich darüber Bücher geschrieben habe. Microservices machen Fachlichkeit und Domain-driven Design wieder wichtiger. Alle diese Punkte sind meiner Meinung nach bei der Software-Architektur wegweisend.

Gute Architektur ist nur mit guter Kommunikation möglich.

W-JAX: Eberhard, auf der W-JAX hältst du eine Session, in der du hinter den aktuellen Hype um Microservices blickst. Was würdest du momentan eher dem Hype zuordnen, was der echten Wertschöpfung, die die Microservices-Idee ermöglicht?

Eberhard Wolff: Für mich sind Microservices ein guter Türöffner, um eine Architektur-Diskussion zu starten und Themen wie Fachlichkeit, Domain-driven Design oder Continuous Delivery ebenfalls anzusprechen. Dafür ist der Hype auf jeden Fall nützlich. Außerdem erlauben Microservices viel stärkere Entkopplung und lösen so viele Probleme klassischer Modularisierung. Mit Self-contained Systems gibt es außerdem einen Best-Practices-Ansatz für Microservices, deren Vorteile in der Praxis schon viele Projekte aufgezeigt haben.